1.1 Field of the Invention
The present invention relates to computer applications and in particular to a method and respective system for client-side interacting with a server-side web application—and vice versa—in a web-based client-server environment, in which a client-side web browser is used as an application user interface.
1.2. Description and Disadvantages of Prior Art
In such environments, traditionally a web browser is used for displaying web pages sent by the web application within a browser application frame and for converting events triggered by one or more user actions within said application frame into a request directed to said server-side web application. As the browser functionality is small compared to stand-alone applications this web user interface may be considered as a “light” version compared to the user interface operated by a stand-alone application without an interconnected web connection.
With reference to FIG. 1 a prior art web-application involving a web-browser 12 as “light” client having a low-level functionality user interface and an application server 14 hosting the application, suffers from a lack of interactivity with the user and from difficult programming models.
Typically a prior art web application works as follows:
On a user action 1 as e.g., clicking on links, pressing buttons, pressing some keys, or activating any interactive component on the page, the web browser 12 makes a request to the server by sending—see reference sign 2—a HTTP request pointing to a URL. Possibly, a set of parameters to be interpreted by the server 14 may be passed with the HTTP request. These parameters may contain information about the interaction the user did on the page and can be passed to the server either as URL-encoded parameters in an HTTP GET request or as data in the body of an HTTP POST request.
This request is processed by a servlet 16 or a JSP which generates an HTML document and sends it back to the web-browser—see reference sign 3.
The HTML document generated by the servlet 16 typically contains links or interactive formular elements with links to other URLs, either to different servlets/JSPs, or to the same servlet 16 with different parameters.
When the user clicks on one of these interactive elements, the browser is redirected to the new URL.
A new HTTP request is sent to the server, which generates a complete new HTML document and sends it back to the browser. The new document replaces the old one, and by that loops 1, 2, 3, the application workflow is run through by this kind of processing user inputs.
However, there are several drawbacks to this general prior art approach:
First, since each user-interaction reloads the whole document, there is a long time delay between the user interaction and the visual response from the application: the whole document has to be transmitted through the network, it has to be displayed again by the browser. Thus it is not possible to build highly-interactive user interfaces, where a large number of user events (mouse events for instance) can be processed by the server 14.
Second, the programming model to realize such applications is complex. Since each user interaction leads to the replacement of the current document with a new document, the logic of the web application program becomes complicated, as current status information about the current session has to be passed to the server in order for being used in the new document.
Third, the programming model of a Web application is completely different from the programming model of a standalone application:
In a standalone offline application, user interface logic can be implemented within a single panel by listening to the events coming from the elements of the panel and responding with property changes in other elements of the same panel (for instance: when button A is clicked, the color of the text B is changed.
In a web application, every user-triggered event is associated with the generation of a new document.
This makes standalone application impossible to be ported to a web application without a complete reengineering of the user interface.
The reason for this drawback is found to be the technical limitations of the client side:
Web browsers were originally designed to display static content (text and images). Thus they offer very limited programming capabilities. Although numerous plug-ins have been developed to enhance the capabilities of the web browsers, browsers are basically still simple client software that can only send requests to a web server and display the returned documents.
To compensate this lack of capabilities of the Web browsers, several specific prior art solutions have been developed until here by the industry, comprising an executable program object for example a Java Script, which is used at the client side as a part of the client-side web application user interface. Examples for this executable code are:
First to be mentioned are JavaScript (or ECMAScript) and Dynamic HTML (DHTML): with this prior art technology a scripting language can be used to modify the content of the displayed document. The script has to be defined in the document loaded by the Web browser. The execution of the script is made by the browser itself. Thus, the server prepares the script, sends it to the browser, but as soon as the document is displayed in the browser, the server has no influence anymore on it.
Second, Java applets: with this specific prior art technology complete Java programs are downloaded on the client and executed in the browser.
These approaches have, however, considerable drawbacks:
JavaScript, which is a registered trademark of Sun Microsystems Inc., allows modification modify “on-the-fly” of elements of the displayed document without having to reload the whole document, but the scripts implementing this user interface behaviour have to be fully defined in the original document downloaded from the server. Once the document is loaded, the server does not interact anymore with the user interface and the logic can't be modified until a new document is loaded.
The latter Java applets are very flexible and can open additional communication channels with the servers, but disadvantageously the whole code of the application to execute has to be downloaded to the client and executed by the browser. This involves also some considerable problems, for instance due to the required download time of the code, risky security issues, and due to the compatibility with the Java virtual machine used by the browser.
Again with reference to FIG. 1, if the user interaction 1 can be processed locally—if the reaction to this interaction is already defined in the JavaScript sent with the HTML document—, the scripts statically embedded in the page can process it and the process stops here. But this is not a satisfying solution due to the reasons described above.
Because of these drawbacks, web applications are still limited to components with a low interactivity, i.e., they generally include text fields, buttons, links in their user interface.
For example, applications using complex mouse interactions, as for instance drag and drop of elements, are difficult to realize.
1.3. Objectives of the Invention
It is thus an objective of the present invention to alleviate the disadvantages of prior art.